Hi Rob. Thanks for getting started on this so quickly!

Unfortunately, the patch as-is doesn't quite fix the problem, as the alloc crate still gets pulled in unconditionally via lib.rs, meaning compilation for a small example with the thumbv7em-none-eabi target fails on the no-alloc branch:

#![no_std]

fn main() {
    let test = bytesize::KIB;
}

error: no global memory allocator found but one is required; link to std or add #[global_allocator] to a static item that implements the GlobalAlloc trait
error: #[panic_handler] function required, but not found

Also, from a code review perspective, it might make more sense to put the #[cfg] on the parse module itself, rather than on the individual items within it.

I guess what I want to know is how much of the library do you need in your no-alloc target?

If it's just the data types that makes things simpler. core includes both fmt::Display and str::FromStr traits so theoretically it might be possible to write these in a no alloc way.

We do run a no-std test on thumbv6m-none-eabi in CI. You can see it in the ensure-no-std/ folder. Can you propose a way to alter that so no-alloc is also checked in CI? Or must we add a new one (sorry this no-alloc world is new to me).

The ensure-no-std project just needs the NoopAllocator removed, at which point it will only compile if the alloc crate is not pulled in by bytesize. I guess adding such an allocator is technically an option for my project, but I don't want to have to manually audit dependencies to ensure that they're not using it.

All I would be after for my use case is the data types, conversions, and constants. The parsing and formatting aren't something I need for now, but I agree that it should be possible to have reduced-scope FromStr/Display implementations. I can imagine other people might want it in the future, but it wouldn't be a breaking change to add.